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Abstract 


This document describes two reference video traffic models for 
evaluating RIP congestion control algorithms. The first model 
statistically characterizes the behavior of a live video encoder in 
response to changing requests on the target video rate. The second 
model is trace-driven and emulates the output of actual encoded video 
frame sizes from a high-resolution test sequence. Both models are 
designed to strike a balance between simplicity, repeatability, and 
authenticity in modeling the interactions between a live video 
traffic source and the congestion control module. Finally, the 
document describes how both approaches can be combined into a hybrid 
model. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are candidates for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8593. 
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Ly 


Introduction 


When evaluating candidate congestion control algorithms designed for 
real-time interactive media, it is important to account for the 
characteristics of traffic patterns generated from a live video 
encoder. Unlike synthetic traffic sources that can conform perfectly 
to the rate-changing requests from the congestion control module, a 
live video encoder can be sluggish in reacting to such changes. The 
output rate of a live video encoder also typically deviates from the 
target rate due to uncertainties in th ncoder rate-control process. 
Consequently, end-to-end delay and loss performance of a real-time 
media flow can be further impacted by rate variations introduced by 
the liv ncoder. 


On the other hand, evaluation results of a candidate RTP congestion 
control algorithm should mostly reflect the performance of the 
congestion control module and somewhat decouple from peculiarities of 
any specific video codec. It is also desirable that evaluation tests 
are repeatable and easily duplicated across different candidate 
algorithms. 


One way to strike a balance between the above considerations is to 
evaluate congestion control algorithms using a synthetic video 
traffic source model that captures key characteristics of the 
behavior of a live video encoder. The synthetic traffic model should 
also contain tunable parameters so that it can be flexibly adjusted 
to reflect the wide variations in real-world live video encoder 
behaviors. To this end, this document presents two reference models. 
The first is based on statistical modeling. The second is driven by 
frame size and interval traces recorded from a real-world encoder. 
This document also discusses the pros and cons of each approach, as 
well as how both approaches can be combined into a hybrid model. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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3. 


Desired Behavior of a Synthetic Video Traffic Model 


A live video encoder employs encoder rate control to meet a target 
rate by varying its encoding parameters, such as quantization step 
size, frame rate, and picture resolution, based on its estimate of 
the video content (e.g., motion and scene complexity). In practice, 
however, several factors prevent the output video rate from perfectly 
conforming to the input target rate. 


Due to uncertainties in the captured video scene, the output rate 
typically deviates from the specified target. In the presence of a 
significant change in target rate, th ncoder’s output frame sizes 
sometimes fluctuate for a short, transient period of time before the 
output rate converges to the new target. Finally, while most of the 
frames in a live session are encoded in predictive mode (i.e., 
P-frames in [H264]), the encoder can occasionally generate a large 
intra-coded frame (i.e., I-frame as defined in [H264]) or a frame 
partially containing intra-coded blocks in an attempt to recover from 
losses, to re-sync with the receiver, or during the transient period 
of responding to target rate or spatial resolution changes. 


Hence, a synthetic video source should have the following 
capabilities: 


o To change bitrate. This includes the ability to change frame rate 
and/or spatial resolution or to skip frames upon request. 


o To fluctuate around the target bitrate specified by the congestion 
control module. 


o To show a delay in convergence to the target bitrate. 
o To generate intra-coded or repair frames on demand. 
While there exist many different approaches in developing a synthetic 


video traffic model, it is desirable that the outcome follows a few 
common characteristics, as outlined below. 


o Low computational complexity: The model should be computationally 
lightweight, otherwise, it defeats the whole purpose of serving as 
a substitute for a live video encoder. 


o Temporal pattern similarity: The individual traffic trace 
instances generated by the model should mimic the temporal pattern 
of those from a real video encoder. 
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o Statistical resemblance: The synthetic traffic source should match 
the outcome of the real video encoder in terms of statistical 
characteristics, such as the mean, variance, peak, and 
autocorrelation coefficients of the bitrate. It is also important 
that the statistical resemblance should hold across different time 
scales ranging from tens of milliseconds to sub-seconds. 


o A wide range of coverage: The model should be easily configurable 
to cover a wide range of codec behaviors (e.g., with either fast 
or slow reaction time in liv ncoder rate control) and video 
content variations (e.g., ranging from high to low motion). 


These distinct behavior features can be characterized via simple 
statistical modeling or a trace-driven approach. Sections 5 and 6 
provide an example of each approach, respectively. Section 7 
discusses how both models can be combined together. 


4. Interactions between Synthetic Video Traffic Source and Other 
Components at the Sender 


Figure 1 depicts the interactions of the synthetic video traffic 
source with other components at the sender, such as the application, 
the congestion control module, the media packet transport module, 
etc. Both reference models, as described later in Sections 5 and 6, 
follow the same set of interactions. 


The synthetic video source dynamically generates a sequence of dummy 
video frames with varying size and interval. These dummy frames are 
processed by other modules in order to transmit the video stream over 
the network. During the lifetime of a video transmission session, 
the synthetic video source will typically be required to adapt its 
encoding bitrate and sometimes the spatial resolution and frame rate. 


In this model, the synthetic video source module has a group of 
incoming and outgoing interface calls that allow for interaction with 


other modules. The following are some of the possible incoming 
interface calls, marked as (a) in Figure 1, that the synthetic video 
traffic source may accept. The list is not exhaustive and can be 


complemented by other interface calls if necessary. 


o Target bitrate R_v: Target bitrate request measured in bits per 
second (bps). Typically, the congestion control module calculates 
the target bitrate and updates it dynamically over time. 

Depending on the congestion control algorithm in use, the update 
requests can either be periodic (e.g., once per second), or 
on-demand (e.g., only when a drastic bandwidth change over the 
network is observed). 
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o Target frame rate FPS: The instantaneous frame rate measured in 
frames per second at a given time. This depends on the native 
camera-capture frame rate as well as the target/preferred frame 
rate configured by the application or user. 


o Target frame resolution XY: The 2-dimensional vector indicating 
the preferred frame resolution in pixels. Several factors govern 
the resolution requested to the synthetic video source over time. 
Examples of such factors include the capturing resolution of the 
native camera and the display size of the destination screen. The 
target frame resolution also depends on the current target bitrate 
R_v, since it does not make sense to pair very low spatial 
resolutions with very high bitrates, and vice-versa. 


o Instant frame skipping: The request to skip the encoding of one or 
several captured video frames, for instance, when a drastic 
decrease in available network bandwidth is detected. 


o On-demand generation of intra (I) frame: The request to encode 
another I-frame to avoid further error propagation at the receiver 
when severe packet losses are observed. This request typically 
comes from the error control module. It can be initiated either 
by the sender or by the receiver via Full Intra Request (FIR) 
messages as defined in [RFC5104]. 


An example of an outgoing interface call, marked as (b) in Figure 1, 


is the rate range [R_min, R_max]. Here, R_min and R_max are meant to 
capture the dynamic rate range the actual live video encoder is 
capable of generating given the input video content. This typically 


depends on the video content complexity and/or display type (e.g., 
higher R_max for video content with higher motion complexity or for 
displays of higher resolution). Therefore, these values will not 
change with R_v but may change over time if the content is changing. 
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| | dummy encoded 
Synthetic video frames 
Video j -------------- > 
Source | 


interface from interface to 
other modules (a) other modules (b) 


Figure 1: Interaction between Synthetic Video Encoder 
and Other Modules at the Sender 


5. A Statistical Reference Model 


This section describes one simple statistical model 
traffic source. 


May 2019 


of the live video 
Figure 2 summarizes the list of tunable parameters 


in this statistical model. A more comprehensive survey of popular 
methods for modeling the behavior of video traffic sources can be 


found in [Tanwir2013]. 
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+ + + + 
Notation Parameter Name Example Value 
+ + + + 
R_v Target bitrate request 1 Mbps 
+----------- 4+------------------------------------ +---------------- + 
FPS Target frame rate 30 Hz 
+----------- +------------------------------------ +---------------- + 
tau_v Encoder reaction latency 0.2 s 
+----------- +------------------------------------ +---------------- + 
K_d Burst duration of the transient 8 frames 
period 
+----------- +------------------------------------ +---------------- + 
K_B Burst frame size during the 13.5 KB* 
transient period 
+----------- +------------------------------------ +---------------- + 
to Reference frame interval 1/FPS 33 ms 
+----------- +------------------------------------ +---------------- + 
BO Reference frame size R_v/8/FPS 4.17 KB 
+----------- +------------------------------------ +---------------- + 


Scaling parameter of the zero-mean 
Laplacian distribution describing 
SCALE_t deviations in normalized frame OLS 
interval (t-t0)/t0 


Scaling parameter of the zero-mean 
Laplacian distribution describing 


SCALE_B deviations in normalized frame 0.15 
size (B-BO)/BO 
+----------- +------------------------------------ +---------------- + 
R_min Minimum rate supported by video 150 kbps 
encoder type or content activity 
+----------- +------------------------------------ +---------------- + 
R_max Maximum rate supported by video 1.5 Mbps 
encoder type or content activity 
+ + + + 


* Example value of K_B for a video stream encoded at 720p and 
30 frames per second using H.264/AVC encoder 


Figure 2: List of Tunable Parameters in a Statistical Video Traffic 
Source Model 
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5.1. Time-Damped Response to Target-Rate Update 


While the congestion control module can update its target bitrate 
request R_v at any time, the statistical model dictates that the 
encoder will only react to such changes tau_v seconds after a 
previous rate transition. In other words, when the encoder has 
reacted to a rate-change request at time t, it will simply ignore all 
subsequent rate-change requests until time t+tau_v. 


5.2. Temporary Burst and Oscillation during the Transient Period 


The output bitrate R_o during the period [t, tttau_v] is considered 
to be in a transient state when reacting to abrupt changes in target 
rate. Based on observations from video encoder output, the encoder 
reaction to a new target bitrate request can be characterized by high 
variations in output frame sizes. It is assumed in the model that 
the overall average output bitrate R_o during this transient period 
matches the target bitrate R_v. Consequently, the occasional burst 
of large frames is followed by smaller-than-average encoded frames. 


This temporary burst is characterized by two parameters: 
o burst duration K_d: Number of frames in the burst event, and 
o burst frame size K_B: Size of the initial burst frame, which is 


typically significantly larger than the average frame size at 
steady state. 


It can be noted that these burst parameters can also be used to mimic 
the insertion of a large on-demand I-frame in the presence of severe 
packet losses. The values of K_d and K_B typically depend on the 
type of video codec, spatial and temporal resolution of the encoded 
stream, as well as the activity level in the video content. 


5.3. Output-Rate Fluctuation at Steady State 


The output bitrate R_o during steady state is modeled as randomly 
fluctuating around the target bitrate R_v. The output traffic can be 
characterized as the combination of two random processes that denote 
the frame interval t and output frame size B over time, which are the 
two major sources of variations in the encoder output. For 
simplicity, the deviations of t and B from their respective reference 
levels are modeled as independent and identically distributed (i.i.d) 
random variables following the Laplacian distribution [Papoulis]. 
More specifically: 
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o Fluctuations in frame interval: The intervals between adjacent 
frames have been observed to fluctuate around the reference 
interval of t0 = 1/FPS. Deviations in normalized frame interval 
DELTA_t = (t-t0)/t0O can be modeled by a zero-mean Laplacian 
distribution with scaling parameter SCALE_t. The value of SCALE_t 
dictates the "width" of the Laplacian distribution and therefore 
the amount of fluctuation in actual frame intervals (t) with 
respect to the reference frame interval t0. 


o Fluctuations in frame size: The output-encoded frame sizes also 
tend to fluctuate around the reference frame size BO=R_v/8/FPS. 
Likewise, deviations in the normalized frame size DELTA _B = 
(B-B0O)/BO can be modeled by a zero-mean Laplacian distribution 
with scaling parameter SCALE_B. The value of SCALE_B dictates the 
"width" of this second Laplacian distribution and correspondingly 
the amount of fluctuations in output frame sizes (B) with respect 
to the reference target BO. 


Both values of SCALE_t and SCALE_B can be obtained via parameter 
fitting from empirical data captured for a given video encoder. 
Example values are listed in Figure 2 based on empirical data 
presented in [IETF-Interim]. 


5.4. Rate Range Limit Imposed by Video Content 


The output bitrate R_o is further clipped within the dynamic range 
[R_min, R_max], which in reality are dictated by scene and motion 
complexity of the captured video content. In the proposed 
statistical model, these parameters are specified by the application. 


6. A Trace-Driven Model 


The second approach for modeling a video traffic source is trace- 
driven. This can be achieved by running an actual live video encoder 
on a set of chosen raw video sequences and using the encoder’s output 
traces for constructing a synthetic video source. With this 
approach, the recorded video traces naturally exhibit temporal 
fluctuations around a given target bitrate request R_v from the 
congestion control module. 


The following list summarizes the main steps of this approach: 


1. Choose one or more representative raw video sequences. 
2. Encode the sequence(s) using an actual live video encoder. 
Repeat the process for a number of bitrates. Keep only the 


sequence of frame sizes for each bitrate. 
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3. Construct a data structure that contains the output of the 
previous step. The data structure should allow for easy bitrate 
lookup. 

4. Upon a target bitrate request R_v from the controller, look up 


the closest bitrates among those previously stored. Use the 
frame-size sequences stored for those bitrates to approximate the 
frame sizes to output. 


5. The output of the synthetic video traffic source contains 
"encoded" frames with dummy contents but with realistic sizes. 


Section 6.1 explains the first three steps (1-3), and Section 6.2 
elaborates on the remaining two steps (4-5). Finally, Section 6.3 
briefly discusses the possibility to extend the trace-driven model 
for supporting time-varying frame rate and/or time-varying frame 
resolution. 


6.1. Choosing the Video Sequence and Generating the Traces 


The first step is a careful choice of a set of video sequences that 
are representative of the target use cases for the video traffic 
model. For th xample use case of interactive video conferencing, 
it is recommended to choose a sequence with content that resembles a 
"talking head", e.g., from a news broadcast or recording of an actual 
video conferencing call. 


The length of the chosen video sequence is a tradeoff. If it is too 
long, it will be difficult to manage the data structures containing 
the traces. If it is too short, there will be an obvious periodic 
pattern in the output frame sizes, leading to biased results when 
evaluating congestion control performance. It has been empirically 
determined that a sequence 2 to 4 minutes in length sufficiently 
avoids the periodic pattern. 


Given the chosen raw video sequence, denoted "S", one can use a live 
encoder, e.g., some implementation of [H264] or [H265], to produce a 
set of encoded sequences. As discussed in Section 3, the output 
bitrate of the liv ncoder can be achieved by tuning three input 
parameters: quantization step size, frame rate, and picture 
resolution. In order to simplify the choice of these parameters for 
a given target rate, one can typically assume a fixed frame rate 
(e.g., 30 fps) and a fixed resolution (e.g., 720p) when configuring 
the live encoder. See Section 6.3 for a discussion on how to relax 
these assumptions. 
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Following these simplifications, the chosen encoder can be configured 
to start at a constant target bitrate, then vary the quantization 
step size (internally via the video encoder rate controller) to meet 
various externally specified target rates. It can be further assumed 
the first frame is encoded as an I-frame and the rest are P-frames 
(see, e.g., [H264] for definitions of I-frames and P-frames). For 
live encoding, the encoder rate-control algorithm typically does not 
use knowledge of frames in the future when encoding a given frame. 


Given the minimum and maximum bitrates at which the synthetic codec 


is to operate (denoted as "R_min" and "R_max", see Section 4), the 
entire range of target bitrates can be divided into n_s steps. This 
leads to an encoding bitrate ladder of (n_s + 1) choices equally 
spaced apart by the step length 1 = (R_max - R_min)/n_s. The 


following simple algorithm is used to encode the raw video sequence. 


r = R_min 

while r <= R_max do 
Traces[r] = encode_sequence(S, r, e) 

r=r+ l1 


The function encode_sequence takes as input parameters, respectively, 
a raw video sequence (S), a constant target rate (r), and an encoder 
rate-control algorithm (e); it returns a vector with the sizes of 
frames in the order they wer ncoded. The output vector is stored 
in a map structure called "Traces", whose keys are bitrates and whose 
values are vectors of frame sizes. 


The choice of a value for the number of bitrate steps n_s is 
important, since it determines the number of vectors of frame sizes 
stored in the map Traces. The minimum value one can choose for n_s 
is 1; the maximum value depends on the amount of memory available for 
holding the map Traces. A reasonable value for n_s is one that 
results in steps of length 1 = 200 kbps. Section 6.2.2 will discuss 
further the choice of step length 1. 


Finally, note that, as mentioned in previous sections, R_min and 
R_max may be modified after the initial sequences ar ncoded. 
Henceforth, for notational clarity, we refer to the bitrate range of 
the trace file as [Rf_min, Rf_max]. The algorithm described in 
Section 6.2.1 also covers the cases when the current target bitrate 
is less than Rf_min or greater than Rf_max. 
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6.2. Using the Traces in the Synthetic Codec 


The main idea behind the trace-driven synthetic codec is that it 
mimics the rate-adaptation behavior of a real live codec upon dynamic 
updates of the target bitrate request R_v by the congestion control 
module. It does so by switching to a different frame-size vector 
stored in the map Traces when needed. 


6.2.1. Main Algorithm 


The main algorithm for rate adaptation in the synthetic codec 
maintains two variables: r_current and t_current. 


o The variable r_current points to one of the keys of map Traces. 
Upon a change in the value of R_v, typically because the 
congestion controller detects that the network conditions have 
changed, r_current is updated based on R_v as follows: 


R_ref = min (Rf_max, max(Rf_min, R_v)) 
r_current = r 
such that 

(r in keys (Traces) and 


r <= R_ref and 
(not (exists) r’ in keys(Traces) such that r <r’<= R_ref)) 


o The variable t_current is an index to the frame-size vector stored 


in Traces[r_current]. It is updated every time a new frame is 
due. It is assumed that all vectors stored in Traces have the 
same size, denoted as "Size_traces". The following equation 


governs the update of t_current: 


if t_current < SkipFrames then 
t_current t_current + 1 
else 
t_current = ((t_current + 1 - SkipFrames) 
% (size_traces-SkipFrames)) + SkipFrames 


where operator "%S" denotes modulo, and SkipFrames is a predefined 
constant that denotes the number of frames to be skipped at the 
beginning of frame-size vectors after t_current has wrapped around. 
The point of constant SkipFrames is avoiding the effect of 
periodically sending a large I-frame followed by several smaller- 
than-average P-frames. A typical value of SkipFrames is 20, although 
it could be set to 0 if one is interested in studying the effect of 
sending I-frames periodically. 
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The initial value of r_current is set to R_min, and the initial value 
of t_current is set to 0. 


When a new frame is due, its size can be calculated following one of 
the three cases below: 


a) Rf_min <= R_v < Rf_max: The output frame size is calculated via 
linear interpolation of the frame sizes appearing in 
Traces[r_current] and Traces[r_current + 1]. The interpolation is 
done as follows: 


size_lo = Traces[r_current] [t_current] 

size_hi = Traces[r_current + 1] [t_current] 

distance_lo = (R_v - r_current) / 1 

framesize = size_hi*distance_lo + size_lo*(1-distance_lo) 


b) R_v < Rf_min: The output frame size is calculated via scaling 
with respect to the lowest bitrate Rf_min in the trace file, as 
follows: 


w= Rv / Rf_min 
framesize = max(fs_min, factor * Traces[Rf_min] [t_current]) 


c) R_v >= Rf_max: The output frame size is calculated by scaling 
with respect to the highest bitrate Rf_max in the trace file, as 


follows: 
w= R_v / Rf_max 
framesize = min(fs_max, w * Traces[Rf_max] [t_current]) 
In cases b) and c), floating-point arithmetic is used for computing 
the scaling factor "w". The resulting value of the instantaneous 


frame size (framesize) is further clipped within a reasonable range 
between fs_min (e.g., 10 bytes) and fs_max (e.g., 1 MB). 


6.2.2. Notes to the Main Algorithm 
Note that the main algorithm as described above can be further 


extended to mimic some additional typical behaviors of a live video 
encoder. Two examples are given below: 


o I-frames on demand: The synthetic codec can be extended to 
simulate the sending of I-frames on demand, e.g., as a reaction to 
losses. To implement this extension, the codec’s incoming 
interface (see (a) in Figure 1) is augmented with a new function 
to request a new I-frame. Upon calling such function, t_current 
is reset to 0. 
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o Variable step length 1 between R_min and R_max: In the main 
algorithm, the step length 1 is fixed for ease of explanation. 
However, if the range [R_min, R_max] is very wide, it is also 
possible to define a set of intermediate encoding rates with 
variable step length. The rationale behind this modification is 
that the difference between 400 and 600 kbps as target bitrate is 
much more significant than the difference between 4400 kbps and 
4600 kbps. For example, one could define steps of length 200 kbps 
under 1 Mbps, then steps of length 300 kbps between 1 Mbps and 2 
Mbps, then 400 kbps between 2 Mbps and 3 Mbps, and so on. 


6.3. Varying Frame Rate and Resolution 


The trace-driven synthetic codec model explained in this section is 
relatively simple due to the choice of fixed frame rate and frame 
resolution. The model can be extended further to accommodate 
variable frame rate and/or variable spatial resolution. 


When the encoded picture quality at a given bitrate is low, one can 
potentially decrease either the frame rate (if the video sequence is 
currently in low motion) or the spatial resolution in order to 
improve quality of experience (QoE) in the overall encoded video. On 
the other hand, if target bitrate increases to a point where there is 
no longer a perceptible improvement in the picture quality of 
individual frames, then one might afford to increase the spatial 
resolution or the frame rate (useful if the video is currently in 
high motion). 


Many techniques have been proposed to choose over time the best 
combination of encoder-quantization step size, frame rate, and 
spatial resolution in order to maximize the quality of live video 
codecs [Ozer2011] [Hu2012]. Future work may consider extending the 
trace-driven codec to accommodate variable frame rate and/or 
resolution. 


From the perspective of congestion control, varying the spatial 
resolution typically requires a new intra-coded frame to be 
generated, thereby incurring a temporary burst in the output traffic 
pattern. The impact of frame-rate change tends to be more subtle: 
reducing frame rate from high to low leads to sparsely spaced larger 
encoded packets instead of many densely spaced smaller packets. Such 
difference in traffic profiles may still affect the performance of 
congestion control, especially when outgoing packets are not paced by 
the media transport module. Investigation of varying frame rate and 
resolution are left for future work. 
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7. 


Combining the Two Models 


It is worthwhile noting that the statistical and trace-driven models 
each have their own advantages and drawbacks. Both models are fairly 
simple to implement. It takes significantly greater effort to fit 
the parameters of a statistical model to actual encoder output data. 
In contrast, it is straightforward for a trace-driven model to obtain 
encoded frame-size data. Once validated, the statistical model is 
more flexible in mimicking a wide range of encoder/content behaviors 
by simply varying the corresponding parameters in the model. In this 
regard, a trace-driven model relies, by definition, on additional 
data-collection efforts for accommodating new codecs or video 
contents. 


In general, the trace-driven model is more realistic for mimicking 
the ongoing steady-state behavior of a video traffic source with 
fluctuations around a constant target rate. In contrast, the 
statistical model is more versatile for simulating the behavior of a 
video stream in transient, such as when encountering sudden rate 
changes. It is also possible to combine both methods into a hybrid 
model. In this case, the steady-state behavior is driven by traces 
during steady state and the transient-state behavior is driven by the 
statistical model. 


transient +--------------- + 
state | Generate next | 
+-----—- >| K_d transient | 

tan + / | frames | 
R_v | Compare against | / E E A + 
-----—- >| previous Re 
| target bitrate |\ 
PoP Sor See SSeS Se + \ PH SSeS a SSSR SSeS + 
\ | Generate next | 
5 eee al > frame from 
steady trace 
States tS = -S sss SS TSS 7e> + 


Figure 3: A Hybrid Video Traffic Model 


As shown in Figure 3, the video traffic model operates in a transient 
state if the requested target rate R_v is substantially different 
from the previous target; otherwise, it operates in a steady state. 
During the transient state, a total of K_d frames are generated by 
the statistical model, resulting in one (1) big burst frame with size 
K_B followed by K_d-1 smaller frames. When operating at steady 
state, the video traffic model simply generates a frame according to 
the trace-driven model given the target rate while modulating the 
frame interval according to the distribution specified by the 
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statistical model. On xample criterion for determining whether the 
traffic model should operate in a transient state is whether the rat 
change exceeds 10% of the previous target rate. Finally, as this 
model follows transient-state behavior dictated by the statistical 
model, upon a substantial rate change, the model will follow the 
time-damping mechanism as defined in Section 5.1, which is governed 
by parameter tau_v. 


Reference Implementation 


The statistical, trace-driven, and hybrid models as described in this 
document have been implemented as a stand-alone, platform-independent 
synthetic traffic source module. It can be easily integrated into 
network simulation platforms such as [ns-2] and [ns-3], as well as 
testbeds using a real network. The stand-alone traffic source module 
is available as an open-source implementation at [Syncodecs]. 


IANA Considerations 
This document has no IANA actions. 
Security Considerations 


The synthetic video traffic models as described in this document do 
not impose any security threats. They are designed to mimic 
realistic traffic patterns for evaluating candidate RTP-based 
congestion control algorithms so as to ensure stable operations of 
the network. It is RECOMMENDED that candidate algorithms be tested 
using the video traffic models presented in this document before wide 
deployment over the Internet. If the generated synthetic traffic 
flows are sent over the Internet, they also need to be congestion 
controlled. 
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